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METHOD AND APPARATUS FOR NEGOTIATION 

Negotiation Framework: Value Proposition 



The negotiation framework aims to provide infrastructure that allows two or more 
independent entities to interact with each other over time to reach agreement on the 
parameters of a contract. It is aimed primarily, though not exclusively, as a means to 
reach trade agreements. It can be used both by automated entities, and by users via 
appropriate software tools. 

Its value to negotiation participants is that it is a prerequisite to provide decision 
support or automation of the negotiation, and hence make the process more efficient. 
Furthermore, they can be confident that the basic rules of interaction in any 
negotiation are standardised, hence reducing the effort to automate many different 
kinds of business interactions. They are able to negotiate simple contracts, where only 
price is undetermined, and more complex contracts where many complex parameters 
depend on each other. Furthermore, the protocols provide the participants with trust 
guarantees, that no party has access to extra information or is able to forge false 
information. 

Its value to negotiation hosts such as auction houses and market makers is that it 
provides a standard framework that all potential customers can use to interact with 
them. However, it does not require a specific market mechanism, so allows the host to 
decide on an appropriate one. It provides standard off-the-shelf market mechanisms 
(eg the English auction), but also allows custom mechanisms to be implemented for 
particular special needs (eg the FCC auction). 
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Requirements on the Negotiation Framework 

1. The framework should be sufficiently formal that automated entities (e-services) 
can interact with it. 

2. The framework should allow negotiation about simple and complex objects. 

3. The framework should be sufficiently general that a variety of different market 
mechanisms (eg 1-1 negotiation, combinatorial auctions, exchanges) can be 
expressed as specific instances of it. 

4. The framework should be built on appropriate security mechanisms and protocols 
that participants can do business in a trusted way. 

5. The framework should allow, but not require, the existence of a third party to 
arbitrate a given negotiation (eg an auctioneer in an auction.) 

6. The framework should support existing ways people do business, as well as 
permitting more radical approaches in the future. 



Negotiation Framework: 



3.4 Service Provisioning: Matchmaking and Negotiation 

The interaction between any two enterprises can be broken down into the following 
phases: 

1 . Identifying potential business partners. This involves looking for businesses 
potentially able to meet your needs through one or more matchmakers, and/or 
using existing business partners. 

2. Determining which business partner to reach agreement with, and identifying 
the terms and conditions of the interaction. This involves introspecting and 
negotiating with the set of potential partners, to select one. 

3. Agree on a contract which formalises the interaction. The contract must not 
only embody the terms and conditions of the agreement reached through 
negotiation, but also specify the way in which the business processes of the 
two organisations will interact. 

4. Execute interaction. 

5. Monitor interaction: This involves managing and monitoring the interaction. 

The provisioning steps (1,2 and 3, above) are described in the following sections. 
There are two aspects to provisioning - the lookup and advertising of capabilities 
done through the match-making communication infrastructure, and negotiation 
between potential partners to decide whether to go ahead, and if so under what terms 
and conditions. Both stages are necessary, but the negotiation stage is often trivial - 
many businesses will offer a simple 'take it or leave it' set of terms and conditions 
including a fixed price, through the matchmaker, and the party making the lookup ' 
simply chooses between the set of 'take it or leave it' offers. 
One can think of matchmaking as a specialised infrastructure service that helps in 
locating potential partners, and negotiation as a set of mechanisms that any service 
can use to reach agreement with other services. 

3.4.1 Matchmaking 

Matchmaking is the process of putting service providers and service consumers in 
contact with each other. The matchmaker is where services that want to be 
dynamically discovered register themselves, and where services that want to find 
other services send their request for matches. Some of the services advertising 
themselves through the matchmaker will be simple end-providers, while others may 
be brokers, auction houses and marketplaces which offer a locale for negotiating with 
and selecting among many potential providers. The matchmaker is a very simple, 
foundational, service on which the rest of the service framework rests, and should be 
as neutral as possible. It is the web-spider search engine of the e-services world Other 
value-added services can take output from matchmakers to assist a service consumer 
in their selection of a business partner - they could provide recommendations over the 
set of results based on quality data, past performance metrics and prices, current state 
of the market etc -however, this is outside the scope of the Service Framework Spec 
but is instead a set of value-added trust services which can be built on top of it. 

For example, a service consumer wishing to place an order for DRAM may send a 
message to the matchmaker, and receive pointers to direct suppliers such as INTEL, 



an industry exchange such as E-HITEX and excess inventory auction sites such as 
fastparts.com. 

In addition to service provider data, matchmakers may contain registrations from 
service consumers who wish to be dynamically discovered by providers. 

A matchmaker receives a lookup request containing a service/product description, 
and returns a set of agreement templates, each with associated negotiation locales. 
The service description specifies the nature of the product/service the initiator wishes 
to trade. 

The matchmaker returns all agreement templates which specify that they are able to 
reach agreements on the given service/product. 

The agreement templates provide details about the kind of agreement that can be 
reached at the associated negotiation locale. They do this by specifying the fields the 
agreement has, and potentially associating constraints with each field. If the locale is a 
catalog for a supplier, the agreement template will specify the values for all fields 
including price, except customer name, address, etc. Hence they are not open to 
negotiation. If the locale is an auction site, the price will not be fixed in the template, 
showing that the price is negotiable. This will be discussed more fully in the section 
on negotiation. 

Optionally, the service provider/consumer initiating the lookup may send an 
agreement template within the lookup request. In this case, the matchmaker returns all 
template/locale pairs with templates that are compatible with that of the initiator. Two 
templates are compatible if they ??? have the same fields, and the constraints on each 
field are not mutually exclusive. 

3.4.1.1 Interactions with Matchmakers 

This section outlines the kinds of interactions that a matchmaker has with service 
provider/consumers. In addition to the matchmaker, the actors are the advertiser, a 
service provider or consumer wishing to advertise its availability to trade, and the 
client, a service provider or consumer wishing to locate potential trading partners. 

1 . The advertiser gets reference to matchmaker. 

2. The advertiser registers an agreement template with the matchmaker. 

3. The client gets reference to matchmaker. 

4. The client sends lookup request to the matchmaker. 

5. Matchmaker responds with a set of (agreement template, negotiation locale) 
pairs. 

In this section, we focus on steps 2, 4 and 5. 
Advertising 

An advertising conversation consists of a simple exchange of two messages. The 
advertiser sends an 'advertise' message, and receives an 'advertise-reply' message in 
response. 

Advertise messages have the following format; 

<ElementType name = "advertise" content="eltOnly" mode 1 =" ope n"> 



Ottribute type ="sender id" > 

<attribute type = ,/ pointer to negotiation locale host"> 

<element type ^"agreement template"> 

</ElementType> 

Advertise reply messages have the following format; 

<ElementType name = "advertise-reply" content="eltOnly" model="open"> 
<element type ="status" > 
<element type ="advertiseID"> 
</ElementType> 

The status element determines if the advertisement was accepted by the matchmaker. 
The matchmaker can reject advertisements is they are not well-formed, or do not 
comply with any advertising restrictions which the particular matchmaker has 
adopted. (For example a matchmaker may accept only proposed agreements to sell, or 
agreements associated with particular kinds of service.) 

The advertiselD can be used by the advertiser to identify it in future interactions with 
the matchmaker, if they wish to change or delete it. To do this, they may use the 
following messages; 

Advertise-retract messages are used to delete an existing advertisement. The message 
is structured as follows; 

<ElementType name = "advertise-retract" content="eltOnly" 
model="open"> 

<element type ="advertiseID"> 
</ElementType> 

In receipt of this, a matchmaker deletes the corresponding advertisement, and 
responds with an advertise-reply message. 

Advertise-modify messages allow the negotiation locale and/or agreement template 
associated with a given advertiselD to be changed. This is equivalent to an advertiser 
sending an advertise-retract message followed by an advertise message, and the 
matchmaker assigning the same advertiselD to the new advertisement. The message is 
structured as follows; 

<ElementType name = "advertise-modify" content="eltOnly" 
model="open"> 

<attribute type ="sender id" > 

<attribute type ="pointer to negotiation locale host"> 

<element type ="agreement template"> 

</ElementType> 

The matchmaker responds with an advertise-reply message, indicating success or 
failure of the proposed modification. 

Lookup 



A lookup conversation consists of a simple exchange of 2 messages. The initiator 
sends a lookup-request message to the matchmaker, detailing the criteria which they 



wish to use to locate potential traders, and the matchmaker replies with a list of 
agreement templates and associated negotiation locales. 

The messages are structured as follows; 

<ElementType name = "lookup-request" content="eltOnly" model="open"> 

<element type ^"agreement template"> 

</ElementType> 

The agreement template specifies the criteria the initiator is interested in. Often, only 
the service/product description section of the agreement template will be instantiated 
(together with the buyer or seller, which will be instantiated to the initiator), and all 
other fields will be left unconstrained. This will allow the initiator to locate all 
potential trade partners for a given product or service description. 

<ElementType name = "lookup-reply" content="eltOnly" model="open"> 
<element type = "lookup result"> 
LIST OF: 

<attribute type ="pointer to negotiation locale host"> 
<element type ="agreement template"> 
</ElementType> 

The lookup result can be success or fail. Fail means that the lookup was ill-formed, or 
could not be processed for some other reason. The list of results give the agreement 
templates and locations of all potential traders. If no lookups are found, the result will 
be success but the list of results will be empty. 

[Possible extensions; 

- Allow initiator to restrict the length of the result. 

- Allow the initiator to accept 'near' matches 

- Allow subscription services; 'notify me if someone registers interest in this 
kind of template'] 

3.4.2 Negotiation 

3.4.2.1 What Can One Negotiate? 

Negotiation is the process by which two (or more) parties interact to reach an 
agreement. Usually this will be about some business interaction such as the supply of 
a service in return for payment. However, the concepts described in this section are 
sufficiently general that they can be used to negotiate other forms of agreement. 

To be able to negotiate with each other, parties must initially share an agreement 
template. This specifies the different parameters of the negotiation (eg product type, 
price, supply date etc). Some of the parameters will be constrained within the 
template (eg product type will almost always be constrained in some way) while 
others may be completely open. The agreement template is decided at the 
matchmaking stage - matchmaking is exactly the process by which one party locates 
other parties with agreement templates compatible with their needs. 

Depending on what parameters a party is willing to negotiate on, it will adopt more or 
less constrained agreement templates. For example, a party that is willing to negotiate 



nothing (such as a catalog) will only advertise a fully instantiated agreement template, 
with a fixed price. A party willing to negotiate features of a product, such as colour, 
as well as price and delivery date, will leave these parameters unconstrained. 

The process of negotiation is the move from an agreement template to an agreement 
which the agreeing parties find acceptable. A single negotiation may involve many 
parties, resulting in several agreements between different parties and some parties 
who do not reach agreement. For example, a stock exchange can be viewed as a 
negotiation where many buyers and many sellers meet to negotiate the price of a 
given stock. Many agreements are formed between buyers and sellers, and some 
buyers and sellers fail to trade. 

After an agreement is reached, it is necessary to formalise this and to determine how 
the business processes will interact with each other. This is the process of moving 
from agreement to contract, and will be dealt with in section ???. 

In this document, we assume that all agreements are between two parties. However, 
the majority of the protocol described generalises in a straightforward way to handle 
agreements between more than two parties. 

3.4.2.2 The General Negotiation Protocol 

When discussing negotiation, it is important to distinguish between the negotiation 
protocol and the negotiation strategy. The protocol determines the flow of messages 
between the negotiating parties - who can say what, when - and acts as the rules by 
which the negotiating parties must abide by if they are to interact. The protocol is 
necessarily public and open. The strategy, on the other hand, is the way in which a 
given party acts within those rules in an effort to get the 'best' outcome of the 
negotiation - for example, when and what to concede, and when to hold firm. The 
strategy of each participant is necessarily private, and hence an exploration of 
appropriate strategies falls outside the Service Framework Specification. 

The Service Framework Specification offers a general negotiation protocol, by which 
service buyers and service sellers can interact. This general protocol can be 
specialised to give specific kinds of negotiation - such as catalog purchase sites, 
auctions, exchanges and multi-attribute one-to-one negotiation. Any trader able to 
participate in the general protocol will be able to participate in a specialised form of it, 
though its strategy may need to be altered. 

There are 2 main roles in negotiation -participant, and negotiation host. The 
participants are those who wish to reach agreement, and usually they are subdivided 
into service buyers and service sellers. The negotiation host is the role responsible for 
enforcing the protocol and rules of negotiation. The host is often a third party outside 
the negotiation - In the case of an auction, the host is the auctioneer. In the case of an 
exchange, the host is the market provider. However, the host may also be a participant 
- In 1 - 1 negotiation or catalog provision, this is usually the case. 



The general negotiation protocol consists of 5 main stages; 



1 . Potential participants request the negotiation host for admission to the 
negotiation. If they are accepted, they receive the agreement template and 
rules specifying how the negotiation takes place (eg is it an auction, an 
exchange, a catalog purchase site, etc.) 

2. Negotiation takes place by participants making proposals. These proposals 
consist of constrained or instantiated versions of the agreement template. 
Participants may make proposals only according to the rules of the negotiation 
received at admission. 

3. During negotiation, the host informs participants of the current status of the 
negotiation, either by sending them current proposals, or by sending some 
form of 'digest' (for example, the current 'best' proposal.) The content of 
these messages is determined by the rules. 

4. In circumstances determined by the rules, the negotiation host identifies 
compatible proposals, and converts them into agreements. 

5. In circumstances determined by the rules, the negotiation host closes the 
negotiation locale, and determines any final agreements. 

3.4.2.3 Protocol Messages 

In this section, we specify the XML messages and conversations associated with the 
general protocol. 

Admission 

The authentication, authorisation and admission procedure is identical to the general 
procedure for admission to services ??described elsewhere in the SFS. 

When admission is successful, the negotiation host sends a message specifying the 
session handle, the agreement template, and a document containing the rules of 
negotiation; 

<ElementType name = "negotiation-rules" content="eltOnly" 
model="open"> 

<element type = "negotiation session handle"> 
<element type ="agreement template" > 
<element type ="negotiation rules"> 
</ Element Type> 

Negotiation 

Negotiation consists of the sending of a series of proposals to the negotiation host. 
Proposals may be sent at any time. If a proposal does not conflict with the negotiation 
rules, the host will accept and process the proposal appropriately. If the proposal does 
conflict with the rules, the host will simply ignore the proposal. NB This means it is 
the responsibility of the proposer to watch the information returned during the 
information display phase to determine if the proposal was successfully submitted. 

<ElementType name = "propose" content="eltOnly" model="open"> 
<element type - "negotiation session handle"> 
<element type ^"proposal" > 
</ElementType> 



The proposal consists of a constrained form of the agreement template, specifying 
attribute values or value ranges which are acceptable to the proposer. For example, a 
buyer may constrain the price attribute to be less than $ 1 00. 

If the negotiation rules allow, a participant may withdraw a previously submitted 
proposal by sending the following message; 

<ElementType name = "proposal-withdraw" content="eltOnly" 
model="open"> 

<element type = "negotiation session handle"> 

<element type ^"proposal" > 

</ElementType> 

» 

Information Display 

The negotiation host sends information about the current status of negotiations to all 
participants, as defined by the information display rules. By default, this consists of a 
set of current proposals. However, in certain circumstances, other information could 
be sent as well or instead. Also, some participants may receive different information 
from others 

<ElementType name - "negotiation-status" content="eltOnly" 

model="open"> 

LIST OF: 

<element type = "negotiation session handle"> 

<element type ="proposal" > 

</ElementType> 

The host expects no reply to these messages. 

Participants may also withdraw from negotiations by sending a negotiation-withdraw 
message. Often it is possible to withdraw at any time, though in some negotiations, 
the negotiation rules will only allow withdrawing in certain circumstances. (For 
example, in an auction, it is not possible to withdraw if you have the best current bid.) 

<ElementType name = "negotiation-withdraw" content="eltOnly" 
model="open"> 

<element type = "negotiation session handle"> 
</ElementType> 

The host responds to a withdraw message by removing all proposals from that 
participant. 

Agreement Formation 

In circumstances determined by the agreement formation rules, the negotiation host 
checks existing proposals for compatibility. If all required attributes of a proposal are 
specified and agreed between at least 2 parties, the host determines which parties 
actually will form an agreement, and notifies successful parties of the outcome by 
sendmg them agreements with all attributes specified. In cases where more than one 
agreement is possible, the negotiation host uses the agreement rules to determine 
which participants have priority. 



<ElementType name = "negotiation-agreement" content="eltOnly" 
model="open"> 

<element type - "negotiation session handle"> 

<element type ^''agreement'^ 

</ElementType> 

The agreeing parties use the agreement in the contract formation phase. (See section 
??) 

Locale Closing 

The negotiation locale closes in circumstances determined by the negotiation rules, 
(eg when all participants have agreed or withdrawn, at a given time, after a period of 
quiescence, etc.) At this point, the host notifies all participants with a negotiation- 
close message, and any further proposals sent are ignored ; 

<ElementType name = "negotiation-close" content="eltOnly" 
model="open"> 

<element type - "negotiation session handle"> 
</ElementType> 

3.4.2.4 Protocol Conversation - Participant 

In this section, we specify the different states a participant can be in, and what 
messages they can send in each state. 

STA TE: Enter Negotiation 

ACTIONS: Sub-conversation associated with authorisation and admission. 
TRANSITIONS: 

Receive 'negotiation-rules' -> Negotiating 

STATE: Negotiating 
ACTIONS: 

Send 'propose' (if negotiation rules currently allow) 
Send 'withdraw proposal' (if negotiation rules allow) 
Send 'negotiation-withdraw' (if negotiation rules currently allow) 
Receive 'negotiation status'. 
TRANSITIONS: 

IF receive 'negotiation-agreement' -> Negotiation-Success 
EF send 'negotiation-withdraw' -> Negotiation-NoDeal 
IF receive 'negotiation-close' and no 'negotiation-agreement' 
-> Negotiation-NoDeal 

STATE: Negotiation-Success 
ACTIONS: 

End of negotiation. Move into contract formation conversations. 

STATE: Negotiation-NoDeal 

ACTIONS: 

End of negotiation. Return to negotiation admission or matchmaking 
conversations. 



3.4.2.5 Protocol Conversations - Negotiation Host 



The negotiation host can carry out multiple conversations with the different 
negotiation participants. These conversations have the following states; 

STATE: Admit Participant . . 

ACTIONS: Sub-conversation associated with authorisation and admission. 
Send 'negotiation-rules' 

TRANSITIONS: 

Send 'negotiation-rules' ->Host Participant 

STATE: Host Participant 

ACTIONS- Send 'negotiation-status' according to the negotiation rules. 

Send 'negotiation-agreement' according to the negotiation rules. 
Send 'negotiation-close' according to the negotiation rules. 

TRANSITIONS: 

Send 'negotiation-agreement' -> Participant-buccess 

Send 'negotiation-close' 

-> End Negotiation 
Receive 'negotiation-withdraw' -> Participant -NoDeal 

STATE: Participant-Success 

A CTIONS: End of this participant' s involvement in negotiation. 

Transfer to contract formation/fulfilment entities. 

STATE: Participant-NoDeal 

ACTIONS- End of this participants involvement in this negotiation. 

Participant must reapply to enter if they wish to in the future. 

STATE: End Negotiation 

ACTIONS: Determine final agreements according to negotiation rules. 
Send final 'negotiation-agreement' messages. 
Send final 'negotiation-status' messages. 
End of all participants' involvement in negotiation. 



Negotiation Framework: Use cases 
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1. Define Admission Policy 



Use Case 


Define Admission Policy 


Description 


The Negotiation Host defines the policies that will be used to 
admit Participants to negotiation. Participants could be 
involved in the definition for negotiations such as auctions or 
RFQs when a participant plays a dominant role. 


Assumptions 




Actors 


Negotiation Host (primary) 
Participant 


Steps 


1 . IF participants are involved in the process, Negotiation 
Host gathers participants input 

2. The Negotiation Host defines the admission policy 


Variations 




Non-Functional 




Issues 


1 . Definition of admission policy. 
1.1 Language for admission pplicy 


2. Define Agreement Template 


Use Case 


Define Agreement Template 


Description 


The Negotiation Host defines the agreement template that will 
be used as a reference during the negotiation. Participants 
could be involved in the definition. 


Assumptions 




Actors 


Negotiation Host (primary) 
Participant 


Steps 


1 . IF participants are involved in the process, Negotiation 
Host gathers participants input 

2. The Negotiation Host defines the agreement template 


Variations 




Non-Functional 




Issues 


1 . Definition of agreement template and relative operations. 
See document on agreement template 



o 



3. Detfone NegottoaUaora IRoDes 



Use Case 


Define Negotiation Rules 


Description 


The Negotiation Host defines the rules that Participants will 
have to comply with during negotiation. Participants could be 
involved in the definition for negotiations such as auctions or 
RFQs when a participant plays a dominant role. 


Assumptions 




Actors 


Negotiation Host (primary) 
Participant 


Steps 


1 . IF participants are involved in the process, Negotiation 
Host gathers participants input 

2. The Negotiation Host defines the negotiation rules 


Variations 




Non-Functional 




Issues 


1 . Definition of negotiation rules . 
1.1 Language for negotiation rules 



4. Defimie Agreement FonmiaHooin IRoDes 



Use Case 


Define Agreement Formation Rules 


Description 


The Negotiation Host defines the agreement formation rules 
that will be used during the negotiation. Participants could be 
involved in the definition. 


Assumptions 




Actors 


Negotiation Host (primary) 
Participant 


Steps 


1 . IF participants are involved in the process, Negotiation 
Host gathers participants input 

2. The Negotiation Host defines the agreement formation 
rules 


Variations 




Non-Functional 




Issues 


1 . Definition of agreement formation rules 
1.1 Language for agreement formation rules 


5. Admission to Negotoatoon 


Use Case 


Admission to Negotiation 


Description 


The Gatekeeper admits Participants to the negotiation on 
verification of their credentials 


Assumptions 





Actors 


Gatekeeper (primary) 
Participant 


Steps 




Variations 




Non-Functional 




Issues 


1 . Credentials 

2. Admission when negotiation has already started 


6. Negotiate 


Use Case 


Negotiate 


Description 


Participants negotiate to get to the formation of agreements 


Assumptions 


A negotiation locale exists and is functional 
A negotiation template exists 


Actors 


Participant (primary) 
Negotiation Host 


Steps 


1 . PERFORM Initiate negotiation infrastructure 

2. REPEAT 

2.1 PERFORM Submit proposal 

2.2 IF Agreement possible 

2.2.1 PERFORM Agreement formation 
ENDIF 
UNTIL Termination 

3. PERFORM Finalize negotiation infrastructure 


Variations 




Non-Functional 




Issues 


1. Is it general enough to cater for any kind of negotiation? 

2. Might be interleaved with the Admission to negotiation 
use case, if that is allowed by the particular negotiation 
rules 



Activity diagram: Negotiate 
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6.1 Initialize negotiation infrastructure 



Use Case 


Initialize negotiation infrastructure 


Description 


Operations and communications preliminary to the negotiation 
process 


Assumptions 




Actors 


Negotiation Host (primary) 
Infrastructure Provider 
Participant 


Steps 




Variations 




Non-Functional 




Issues 




6.2 Submit proposal 


Use Case 


Submit proposal 


Description 


Participant submits a proposal that is validated against the 
agreement template and the negotiation rules 


Assumptions 


A negotiation locale exists and is functional 
An agreement template exists 


Actors 


Participant (primary) 
Negotiation Host 


Steps 


1 . Participant send a proposal to the negotiation table 

2. Negotiation Host (in the role of proposal validator), 
validates the proposal against the negotiation template (is 
the proposal relative to the object we are negotiating over? 
Is it well formed? Is it conforming to allowed expiration 
time?...) 

3. If the proposal is not valid, use case ends 

4. Negotiation Host (in the role of protocol enforcer) 
validates the proposal against negotiation rules (is the 
submitter's turn? Does the proposal comply with the 
improvement rules? Is negotiation not terminated 
already?) 

5. If the proposal is valid, the current set of proposals and 
depending data structures are updated accordingly and 
participants are notified, as defined by visibility rules and 
information filtering rules. 


Variations 




Non-Functional 




Issues 


1 . Are proposal validator and protocol enforcer fully fledged 
roles or just responsibilities of the Negotiation Host? 

2. Operations such as proposal validation against negotiation 
template and agreement rules might be difficult to 
implement. The big advantage though is that this makes it 
very easy to explain the general protocol. 



3. Definition of negotiation template and relative operations. 
<Pointer here to document on negotiation template> 

4. Definition of negotiation rules. 

4.1 Language for negotiation rules 



Activity diagram: Submit proposal 
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6.3 Withdraw proposal 



Use Case 


Withdraw proposal 


Description 


Participant requests to withdraw a proposal 


Assumptions 


A negotiation locale exists and is functional 
An agreement template exists 


Actors 


Participant (primary) 
Negotiation Host 


Steps 


1 . Participant send a request to withdraw a proposal to the 
negotiation locale 

2. Negotiation host (playing the Proposal validator role) 
checks that the withdraw request refers to a proposal that 
is currently on the table 

3. If this is not the case, use case ends 

4. Negotiation host (playing the Protocol enforcer role) 
validates the withdraw proposal request against 
negotiation rules fis nronosal withdrawal allowed in 
general? is it allowed to withdraw this particular proposal? 
Is negotiation not already terminated?) 

5. If the withdraw proposal request is accepted, the current 
set of proposals and depending data structures is updated 
accordingly and participants are notified. Also, depending 
on the negotiation rules, agreement formation can be 
triggered. 


Variations 




Non-Functional 




Issues 


1 . Same issues as in submit proposal 
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2 6.4 Agreement formation 



Use Case 


Agreement formation 


Description 


The Negotiation Host (in the agreement maker role) converts 
of a set of proposals, into a set of agreements. 


Assumptions 


A negotiation locale exists and is functional 
A negotiation template exists 


Actors 


Negotiation Host (primary) 


Steps 


1 . Negotiation Host (in the agreement maker role) looks at 
the current set of proposals to determine whether 
agreements can be made 

2. Negotiation Host (in the agreement maker role) applies tie- 
breaking rules if that is the case 

3. Negotiation Host (in the agreement maker role) creates the 
possible agreements given the proposals on the table and 
the resolution rules 

4. Negotiation Host notifies the participants of agreements 
that have been made 


Variations 




Non-Functional 




Issues 


1 . Is agreement maker a fully-fledged role or just a 
responsibility of the Negotiation Host? 

2. Definition of agreement formation rules 

2.1 Language for agreement formation rules j 



Activity diagram: Agreement formation 
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6.5 Finalize negotiation locale 



Use Case 


Finalize negotiation infrastructure 


Description 


Operations and communications posterior to the negotiation 
process 


Assumptions 




Actors 


Negotiation Host (primary) 
Infrastructure Provider 
Participant 


Steps 




Variations 




Non-Functional 




Issues 




7. Withdraw from negotiation 


Use Case 


Withdraw from negotiation 


Description 


Participant requests to withdraw from negotiation, and 
negotiation rules permitting, Negotiation Host acts 
accordingly 


Assumptions 


The participant is taking part in the negotiation 


Actors 


Participant (primary) 
Negotiation Host 


Steps 


1 . Participant requests to withdraw from negotiation 

2. If the participant has pending proposals, the negotiation 
host attempts to withdraw them 

3. If the proposals could be withdrawn, the participant is 
withdrawn from negotiation, otherwise the request is 
rejected 


Variations 




Non-Functional 




Issues 





Negotiation Framework: Security and Trust 



Underlying Messaging Infrastructure 

Depending on the security of the underlying message infrastructure, the negotiation 
framework will be able to provide different levels of trust. Here we outline the 
requirements to provide the maximum level of trust, but fallback positions should be 
considered in different circumstances. 

Privacy - 

Negotiation participants should be confident that any message sent to the negotiation 
locale will only be revealed to other participants. 

Non - disruptability - 

The locale should not be able to have proposals (or other messages) posted to it or 
deleted from it without the referee's acceptance. 

Uniform view - 

Participants should be able to guarantee that the view they have of the locale is 
accurate, and identical to the view other (similar) participants have. 

Fairness of proposal arrival - 

Participants should not be disadvantaged in tie-break procedures if their connection to 
the locale is slow. (In other words, if they send a bid, and another participant sends an 
identical bid later but over a faster connection, the other participant shouldn't win.) 

Which of these requirements can be achieved without assuming that the negotiation 
host is a trusted third party? 



Negotiation Host 


Entity responsible for creation and enforcement 
of rules governing participation, execution, 
resolution and termination of a negotiation. 


Participant 


Entity participating in a negotiation by posting 
proposals according to the rules provided by the 
negotiation host. 


Negotiation locale 


Location where negotiation proposals are posted 
according to the rules enforced by the negotiation 
host. 


Infrastructure provider 


Provider of the underlying communications 
infrastructure of the negotiation locale. 


Gatekeeper 


Sub-role of negotiation host. Responsible for 
enforcement of policy governing admission to a 
negotiation. 


Participant credentials 


Information, with appropriate trust guarantees, 
about a participant's attributes, capabilities, etc. 


Admission policy 


Policy used for determining who is allowed to 
participate in a given negotiation. 


Proposal 


Specification of potential value ranges in the 
agreement template a participant is willing to 
accept. 


Negotiation table 


A negotiation locale with 1 buyer and 1 seller. 


Auction room 


A negotiation locale with 1 seller and many 
buyers. 


Exchange floor 


A negotiation locale with many buyers and many . 
sellers. 


Proposal validator 


Sub role of negotiation host: responsible for 
ensuring that a proposal is well-formed. 


Agreement template 


A prototype specifying what is to be negotiated, 
and the possible values different parts of the 
prototype can range over. 


Proposal well-formed-ness 


A proposal is well formed within a given 
negotiation if all prototypes within it are 
subsumed by the agreement template. 


Proposal expiration time 


A parameter in a proposal defining when it no 
longer can be considered valid. 


Negotiation rules 


Rules determining the mechanism by which 
negotiation proceeds - who may make a proposal 
when, how existing proposals affect what 
proposals may be made. 


Posting rule 


Negotiation rule determining in what 
circumstances a participant may post a proposal. 


Visibility rule 


Negotiation rule specifying whom, among the 
participants, has visibility over a submitted 
proposal. 


Display rule 


Negotiation rule specifying if and how the 
referee notifies the participants that a proposal 
has been submitted - could either be by 





transmitting the proposal unchanged or by 
transmitting a summary of the situation. 


Improvement rule 


Negotiation rule specifying, given a set of 
existing proposals, what new proposals may be 
posted. 


Withdrawal rule 


Negotiation rule specifying if and when 
proposals can be withdrawn from negotiation, 
and policies over the time expiration of 
proposals. 


Termination rule 


Negotiation rule specifying when no more 
proposals may be posted (e.g. a given time, 
period of quiescence, etc.). 


Protocol enforcer 


Sub-role of negotiation host. Responsible for 
ensuring that participant's proposals are posted 
according to the negotiation rules. 


Agreement 


A configuration of the attributes associated 
agreement template that is understood by the 
participants as being fully defined, together with 
the identification of two (or more?) participants. 


Agreement formation 


The conversion of a set of proposals, at least one 
pair of which intersect, into a set of agreements. 


Agreement maker 


The entity responsible for agreement formation. 


Agreement formation rules 


Rules responsible for determining, given a set of 
proposals at least one pair of which intersect, 
which agreements should be formed. 


Tie-breaking rule 


A specific agreement formation rule applied after 
all others. 



Negotiation Framework: Roles and Responsibilities 



Business level view 

Role 

Negotiation host 
Responsibilities 

Admission policy creation 
Admission policy enforcement 
Negotiation template selection 
Proposal validation (against the agreement template) 
Negotiation rules creation 
Negotiation rules enforcement 
Agreement formation rules creation 
Agreement formation rules enforcement 
Communication infrastructure provision 
Protocol-level security enforcement 
Collaborations 

Participant 

Role 

Participant 
Responsibilities 

Negotiation 
Collaborations 

Negotiation host 

Next level of refinement: breakdown of the Referee 
responsibilities 

Role 

Infrastructure provider 
Responsibilities 

Communication infrastructure provision 

Reliable messaging 

Auditable logging 

Transport security enforcement 
Collaborations 

Negotiation host 

Role 

Proposal validator 
Responsibilities 

Proposal validation (against the negotiation template) 



Collaborations 

Negotiation host 

Role 

Gatekeeper 
Responsibilities 

Admission policy enforcement 
Collaborations 

Negotiation host 

Role 

Protocol enforcer 
Responsibilities 

Negotiation rules enforcement 
Collaborations 

Negotiation host 

Role 

Agreement maker 
Responsibilities 

Agreement formation rules enforcement 
Collaborations 

Negotiation host 



Proposal Validator: 

A module that validates proposals against an agreement template. 

An agreement template is a sort of a standard form that proposals must comply with. 

Negotiation Locale: 

A module where validated proposals are posted and forwarded to the relevant parties in 
the negotiation process. (Relevant information other than validated proposals about the 
negotiation process may be transported using the negotiation locale) 
Proposal Compatibility Checker: 

A module that compares pairs of proposals that have being posted on the negotiation 
locale. It returns information on whether the two proposals are compatible with each 
other. 

Protocol Enforcer: 

A module for rejecting invalid proposals 
Information Editor: 

A module for summarizing information related to the negotiation process and for feeding 
it back to the negotiation locale 

Timer: A timer module 

Agreement Maker: 

A module responsible for refining an agreement that is possible given two or more 
compatible proposals 



i 1 

ctf O 

o <3 

Ph > 



i — i ?-i 

O <D 

o o 

o % 

o ^ 



o 
o 

a 
o 

O 

bX) 




— H i—l * . 



o 

a. 
o 



ctf O 

o eg 

p . 

O ^ 

o. > 



r— I ?-| 

O <D 

O O 

•4— > ,0 

o ^ 

Oh W 



o 
o 

_! 

a 
o 

+-> 
O 



O 



c2 w 



-4- 



* g a 



s 

H 



G 

o 



a 
o 



co ^2 



o 

$-1 
Ph 

13 



i 



o 

^— > 
O 



• 1— I 

o 

.2 



CO 

F- I CO 

CO r ^ 



CO 



O o 
O o 



o 

CO 

<D 

CO 

4=5 



5-1 

CO 



o 

x o 



o 



O 



co 

O 
"3 



CD 



O 

CD 



CD 
CD 

CD CD 



co 
CD 



o 



CO 

CD 



O 

CD 

O 



CD 



CO 

CD 



> 

O U <-H 

ft CD 03 

O ^3 fa 

n .3 ft 



t5 
o 

ft 

CO CO 

^ CD 
CO ^ 

<D " 

s .a 

s .a 

toX) 

•9 I 



5b £ 

CD 

CD a 

£ .2 

_?D c3 

o t4 



o 

■s 

■ i-H 
^— » 

o 
bo 

CD 



CO 

43 



CD 



CD 

CO 

0 



CO 
CD 



CO 
CO 

O 

.2 o 

s I 

CD Js^ 
M 



a 

CD 



£ P .a 



too 



£ CD 

H cfcj 



o 

CD 



X! 

t 

O 

o 

U 



go 
S3 

o 
o 



o 

CD 



GO 



oo O <D 

PQ < o 



• i-H 

o 

co 



co 

a 

co 

• i-H 
O 

o 



0 
o 

CO 
?-H 

^ co 
O o 

° 



PQ PQ & 




o 



o 

a 

GO 

O 



< 



CO 

O 

a 
o 

• 1— I 

o 

CD 



O 



ft 



5-H 

O 

> w 



13 



CO 

O 
Oh 



o 

o 

o 
o 



I I 



S 

bJO 



I 



&4 



5=3 
O 

• rH 

o 

CD 



CD 



O 
3 



CD 

a 



GO 
C+H 



o 



o 

GO 

o 



CD 
J* 
CO 



CD 

E 



CD 
CO 



c 
E 
I 



CD 

LLJ 

O 

a 
o 



CO 

o 
X 
c 
o 

o 

CD 



O CO 
CO Q 

E -£= _a 
5 § w $ 



CD 

O 





















.1 












o 












CO 






a. 







i2 

CD 

E 

CD 

a? 

% 

CO 

E 







o 


L. 

CD 




CO 






CO 






a 


C 




o 


LLJ 




Q_ 


toco 




cept 


g 




o 






CD 


0_ 








1 i_ 






CD 






CL 






CD 






CD 










E 








CO 




CD 


o 




# 



CO 



co 
CD 

o 



o 

a 

• • 2 

P co 

O .2 

z < 

bX) 3a 
<i> Q 



(D 



3 s 



a> 
H 

CD 

S 



O 

• i— t 
+-» 

O 



O 



7^ co c3 



£D <D OX) 

£ < 



a> <u <u 

a a a 
*B 

Q 

I l l 



IB tB 
<u a> 

Q Q 



bX) 



o 

i-H 

t3 



o 

• i-H 

o 

OX) 



o B 



^3 



I I 



o 



o 
too 

CD 

eg 

CO 

<D 

CO 
CO 

D 



o 

Q_ 
C 

.o 

S2 
E 

CO 
CD 

I 




o 



c3 



O 

CO 

<D 

CO 

O 

CO 

D 



\ ! 



CD 

S a> 

85 

CD ^ 



o 
o 

CD 
CD 
C 

Q 



CO 
CO 

E 

5 



CO CO 
Q_ .Q- 

!S2 ^ 

co co 
CL CL 
CO 



X 



\ 



CO 

o 

1-1 

CD "43 
CD 



CO 

o 

CD 

c 
E 

& 

CO 



c: c 

CO co 

o o 

CO CO 

cl a. 

CO 



O 

W) 

$-1 

GO 

on 

GO 



a 
o 

• F-H 

• rH 
+- » 

o 

bD 



o 
o 

I— I 

a 
o 

■S3 

• i-H 
+-> 

O 

bO 
N 

« i-H 

13 

• i-H 

• 1—1 

a 

i 



O 

Oh 
O 

Ph 



■§ 

00 



o o 

Ph 



*-H 

Ph 

I 

+-> 

• i-H 



13 
o 
o 

^ o 



o 



^— > 

o 

bX) 
N 

» i-H 

13 
a 

• i-H 

IX, 



I I I I 



o 




o 

CD 

CO 

CD 

CO 

CD 

CO 



. Q) 

-' XI 

0) Q_ 

2 -2 
CL o 



5 



X 



O 

5 

to 

c 

c 
o 

c5 



/ .2 



o 
en 
CD 
c 

CD 
N 



CO 



\ 



\ 

! 
I 

; 



A 



I 



\ I 

\ i 



2. 

CO o 
Q- 

0) ,? 



o 
c 

CO 



o 

8-1 



.2 
o 

CD 



J 



/ 

A 
/Y^CD 



O 

o3 

\ i 

J c 

CD 

E 

CD 



ta / \g 
-S g. 



< 



e 

E 



E 

Q 



13 

CO 

O 

GL / 



a. 



CO 
</> 

o 

Cl 

2 

CL 

1 

jc 



u 
2 

CO 



c 

.2 
• 

o 

O) 
CD 

c 

CD 
N 

"CO 

c 



CL .9. 



; -T\ « 



CO <o 
CL CL 
co 



o 



o 
o 

a> 

CO 

as 



O 

8 



3 

u 

ft 

• rH 

o 

Ph 



cd 

GO 

O 
O 

CD 



GO 

CD 



03 

> 

H— > 

CO 

O 

EC 



cd 

GO 

O 

a. 
o 

<D £ 



CO 
CD 

•4— > *— I 

cd r CD 



& -3 



cd 

GO 

o 

go 

p^ 



GO 

cd 



a 
o 



cd 



CD 

S 

CD 

cd P 



O 



r- 1 cd 

CD 
> 



O 

CD 



03 <3 

J> CD 

13 ^ 

CO ^ 

Oh .S 

O cd 

Ph cd 

I 



$-H 

CD h_ 

w ^ 
o 

O 

o 



CO 

CD 
i— i 



o a 

Ph O 



5-h 

CD 

a 



CD 



CD 
CD 



tH -rt CD 




o 



O 

toJO 

O 

<D 



Oh 



T3 
0) 

o 

CD 
CD" 

"co 

CO 

o 

e 

CL 



co 

3 



.22 
o 



■o 

CD 



1 1 

o g 

a. =j 

CO 



CO 
CO 
CD 

c 

I 

CD 

M 

"V CO 

1 2 

CO 
CO 

o 

CL 

2 

CL 



CD 
CO 
O 
CL 

2 

CL 



CL 

E 
o 
o 



o 

TO 

8 

CL 

o 

1— 
CL 



co w 




c 
o 

TO 

o 

CD 
CD 



— CO- - 

0) 

"a_ 

E 
o 
o 

75 
to 

a 

s 

CL 



CL 
CD 
O 
O 
CO 

To 
co 
o 

CL 

CL 



o 



OS 



o 

O 

GO 



Ph 



CO 

II 

QO) 
CO 



A 



iS 

CO 



CO 

c 
a> 

E 

CD 
2> 

03 



CO 

5 

S- CD 

r -9 

CD 



CO I ~ 



E 

cd 

-4— » 

JO 



cn 

c 
a) 

E 

a> 

o> 

CO 

c 



0) 



to 
o 

q= 

c 
o 
a 



y 



3 

CO 

<D 



CO 

■4—* 

c: 

CD 

E 

CD 
CD 



o e 

CD 



CO 

^ I 

o g 
ca 



£= 
LU 



/ . 



o 



O 

CO 



1/3 



^3 JU 

J3 5 
5 * ^ * 



o 



43 
43 



^ .g 3 i2 

bp £ > Q « ^ 

CD 

I I I I I 



JT 1 • i— i 



I 

a 
o 

• r-H 



H 



C/3 

o 

o3 



O 



■a 

I 



o 



< 

I 

X! 



c/3 

o 
o 



co 
O 

a 
o 

OS 

H— > 
O 

CD 



CO 

Hi 

cd 

•a 



CD 



CD 

H 

I 



PQ 

<D 
CO 

• i— i 
<D 

w 

a 

CD 

CO 



CO 



CD • rt 

I 



CO 

CD 



t 

CD 

H 

CD 

a 

CD 
CD 
?-h 
W) 

CD 

a 

CD 

Q 



3 3 



CO 

co 
O 

ft 

O 

CO 



CO 



a> 

ft 

cd" 



CO 
CO 

O 



a 

CD 



CO 

a> 

*ft 

& 

CO 

CD 
43 

^) 

CD 

CO 

CO 
CD 



ft ft w 

o o o 

^ ^ o 

co co OX) 

^ ^ CD 

<3 £ 



<D 
CO 

S3 



<D 

a 

CO 



<D 

• 1— I 

* -§ 

-° ft 

.in & 
^ o 
o 

4— > 

• »— i 
o 

CO 

CD 



•3 

O 

ft 

CD 



43 N 

-4— > • I 



43 

<D 
43 



o 



X 



CO 

a> 

CO 

<D 

Q 



CO 

CD 

-a 

O 

CD 

43 
O 

3* 

CO 

CD 
43 



5— ( 

o 



CD 

ft 13 



CD 

o 

o 



CD 
43 

CO 

PQ 

T3 

a 

a 
a 

Q 



0 



*3» 



I 

co 

13 

co 
O 
Pn 
O 



■§ 

CO 

o 

a 
o 

i 



l 



O 



^ O > 

. o ^ 

Oh O 

CD j. 



<H-H 

o 



•s 

co 



rP <D 

P - r& 

•i—i r rt 

S & ^ 

T3 CO 

• h O D 

S hi 



2 

CO 



Q a 



^3 



co *P 

« t 

CO CO 

O Ou co 

H Ph 'S 



S3 



CO 



- S ^ 

<u o 

-2 Ph 

1 IS 

0 ,*- U| co 

CL, CO 

a t3 p< 

S ^ 0> 

<U <D P 

>> O ^ 

5 <L> ^ 

1 I ^ 

P 2 ?-i 

CO • i-H 



"5 

CO 



2 Si 



o 

Ph 



o 

CO 

-+-> 

CO (D 

O 03 
O o 

fa ^ 
Ph ^ 

CD 



o 

'5 s 



CO 

CO " 

> ctf 

<D ^ 

CD J" . 

co ~ co 

S g 



CD 
co 



CD 



O 
Oh 



^3 ^ 
CO ^ 

3 o 



O 

a 



•=d o G S 



CO 

W is 
l 



^ co g 

* * i 

CD ^ S 

o3 ~ CO 



O 



CO 



s 



cd 

^ <D 
CD ^ 



CD 

o 



O 

o 



CD 

CD 
CD 

& 

CD 



CD 

a 

CD 
> 
O 

$-! 



CD o3 

^ o 

o g 

ctf o 

S M 

C -4— > 

rS ° 

vh 3 

CD c3 



-a 
o 



o 

CD 



CD 
Qh CD 



•2* 



CD 

• l-H 

o 

CD 
CD 

a 

-4— » 

• i-H 

cd 

t: 

CD 
O 

cd 

Cd J— ( 

\p cd 
<D CD 

1 
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CLAIMS 

1 . A computer system for allowing negotiation between a plurality of 
entities, the computer system comprising a computer network having a 
plurality of computer nodes; a computer node being arranged to define 
the negotiation between the entities with a set of negotiation activities; 
wherein the computer node is operable to implement a plurality of 
negotiation rule sets, each rule set constraining the set of negotiation 
activities to a specific negotiation type, thereby allowing an entity to 
select at least one of a plurality of negotiation types. 

2. A computer system according to claim 1 , wherein a plurality of nodes 
are arranged to define the negotiation between the entities with a set of 
negotiation activities; wherein each of the plurality of nodes are 
operable to implement a plurality of negotiation rule sets. 

3. A computer system according to claim 1 or 2, wherein at least one of 
the entities is a software negotiation agent. 

4. A computer system according to claim 3, wherein the computer node 
incorporates the software negotiation agent. 

5. A computer system according to claim 1 or 2, wherein at least one of 
the entities is a user. 

6. A computer system according to any preceding claim, wherein in at 
least one of the entities is a negotiation host and at least another of the 
entities is a negotiation participant. 
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7. A computer system according to any preceding claim, wherein at least 
one of the rule sets constrains the negotiation activities to an auction 
and at least another rule set constrains the negotiation activities to a 
one on one negotiation. 

8. A computer system according to any preceding claim, wherein the 
negotiation activities include a proposal validator for validating a 
proposal, received from an entity, with an agreement template, a 
negotiation locale for providing a validated proposal to a proposal 
compatibility checker for comparing proposals received from the 
negotiation locale to determine compatibility of received proposals to 
establish an agreement. 

9. A computer system according to claim 8, wherein the negotiation 
activities further includes a protocol enforcer for rejecting invalid 
proposals. 

10. A computer system according to claim 9, wherein the negotiation 
activities further includes an information editor for providing to the 
negotiation locale summarized proposal information. 

1 1. A computer system according to claim 10, wherein the negotiation 
activities further includes an agreement maker for determining criteria 
for establishing an agreement based on the received proposals. 

12. A computer system substantially as hereinbefore described with 
reference to the accompanying figures. 

13. A computer node for coupling to a computer system to allow 
negotiation between a plurality of entities, the computer node 
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comprising a processor, the processor being arranged to define the 
negotiation between the entities with a set of negotiation activities; 
wherein the processor is operable to implement a plurality of 
negotiation rule sets, each rule set constraining the set of negotiation 
5 activities to a specific negotiation type, thereby allowing an entity to 

select at least one of a plurality of negotiation types. 

14. A computer node according to claim 13, wherein at least one of the 
entities is a software negotiation agent. 

10 

15. A computer node according to claim 14, wherein the computer node 
incorporates the software negotiation agent. 

16. A computer node according to claim 13 or 14, wherein at least one of 
1 5 the entities is a user. 

17. A computer node according to any of claims 13 to 16, wherein in at 
least one of the entities is a negotiation host and at least another of the 
entities is a negotiation participant. 

20 

18. A computer node according to any of claims 13 to 17, wherein at least 
one of the rule sets constrains the negotiation activities to an auction 
and at least another rule set constrains the negotiation activities to a 
one on one negotiation. 

25 

19. A computer node substantially as hereinbefore described with 
reference to the accompanying figures. 

20. A method for selecting a negotiation type between a plurality of entities 
30 via a computer network having a plurality of computer nodes, the 



1 




General Negotiation Framework 

method comprising defining in a computer node a set of negotiation 
activities; allowing an entity to select via the computer node at least 
one of a plurality of negotiation rule sets, each rule set constraining the 
set of negotiation activities to a specific negotiation type, thereby 
5 allowing an entity to select at least one of a plurality of negotiation 

types. 

21. A method for selecting a negotiation type substantially as hereinbefore 
described with reference to the accompanying figures. 

22. A computer system for allowing negotiation between a plurality of 
entities, the computer system comprising a computer network having a 
plurality of computer nodes; a computer node being arranged to define 
the negotiation between the entities with a set of negotiation activities; 
wherein the negotiation activities include a proposal validator for 
validating a proposal, received from an entity, with an agreement 
template, a negotiation locale for providing a validated proposal to a 
proposal compatibility checker for comparing proposals received from 
the negotiation locale to determine compatibility of received proposals 
to establish an agreement. 

23. A computer system according to claim 22, wherein the negotiation 
activities further includes a protocol enforcer for rejecting invalid 
proposals. 

25 

24. A computer system according to claim 23, wherein the negotiation 
activities further includes an information editor for providing to the 
negotiation locale summarized proposal information. 
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25. A computer system according to claim 24, wherein the negotiation 
activities further includes an agreement maker for determining criteria 
for establishing an agreement based on the received proposals. 

26. A computer node for coupling to a computer system to allow 
negotiation between a plurality of entities, the computer node 
comprising a processor, the processor being arranged to define the 
negotiation between the entities with a set of negotiation activities; 
wherein the negotiation activities include a proposal validator for 
validating a proposal, received from an entity, with an agreement 
template, a negotiation locale for providing a validated proposal to a 
proposal compatibility checker for comparing proposals received from 
the negotiation locale to determine compatibility of received proposals 
to establish an agreement. 

27. A computer node according to claim 26, wherein the negotiation 
activities further includes a protocol enforcer for rejecting invalid 
proposals. 

28. A computer node according to claim 27, wherein the negotiation 
activities further includes an information editor for providing to the 
negotiation locale summarized proposal information. 

29. A computer node according to claim 28, wherein the negotiation 
activities further includes an agreement maker for determining criteria 
for establishing an agreement based on the received proposals. 
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ABSTRACT 

METHOD AND APPARATUS FOR NEGOTIATION 

5 

A computer system for allowing negotiation between a plurality of entities, the 
computer system comprising a computer network having a plurality of 
computer nodes; a computer node being arranged to define the negotiation 
between the entities with a set of negotiation activities; wherein the computer 
10 node is operable to implement a plurality of negotiation rule sets, each rule set 
constraining the negotiation activities to a specific negotiation type, thereby 
allowing a plurality of negotiation types to be selected by an entity. 
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